# Payment processes

# Overall process

# Sales / customer communication

# After-payment process

# TODO: Further processing

# bobsys ???

# settlements ???

# How is "paid" represented in SBO?

# How is "paid" represented in Accounting?

# Shop + Payment Gateway process

# Deprecated: To be replaced!

# Simplified "shop only" process

Usage of payment gateway imposes redundant steps and information:

  • PayGW local DB storage
    • Results from Concardis,
      especially customers, persons, payment instruments, Concardis orders.
    • Copy of some shop data
  • Handling of customers, payment instruments and Concardis orders.
  • Queries shop DB for its order entity (used for determination of allowed payment methods).

PayGW was meant to implement these paradigms and fails:

  • Abstraction over different payment providers.
    This does currently not apply and violates an agile rule:\

    Don't implement what you don't need now.

  • Reduction of roundtrip times.
    Total failure: Shop needs the same amount of API requests as it would when contacting Concardis on its own. There's no benefit in caching the Concardis results.
  • Decoupled services.
    In order to determine allowed payment methods PayGW directly contacts the shop DB, violating separation.
    This could get circumvented by handing over the needed order information from shop to PayGW. However, shop owns this info and should be the place where payment methods get evaluated.
  • Stability.
    Implementing another service without immanent need decreases stability by default.

The goal is to completely remove PayGW and let shop handle everything. Since the order confirmation page is implemented as a separated project inside the shop code this is perfectly possible.

Page Info: Created by GitHub on Jun 9, 2023 (last updated a minute ago by GitHub)